JSON型 (DB)
stringを突っ込む感じ
ただし、validなJSONでないとerrorになる
内部で最適化されるので速い
これは文字列型にJSONを入れたものからアクセスするより速いという意味
JSONを扱いやすいように関数が提供されている
e.g. 中身を検索しやすい、中身を更新しやすい
indexが使えない
ただし、特定のfieldだけindexをはる方法はあるらしい
型の指定としては、以下のようにjsonを指定するだけ
code:sql
CREATE TABLE book (
...
tags json DEFAULT NULL,
) ENGINE=InnoDB;
つまり、クソ雑だということ
fieldの型は指定できないし、もちろん参照をはることもできない
データ的にはtags.item.idが、item tableを見てたとしても、そこに関連性をもたせることはできない
JSONは絶対に必要ではない限り利用はおすすめしません。MySQLでドキュメント指向のNoSQLデータベースを模倣できるかもしれませんが、SQLの多くの利点が損なわれてしまうでしょう。本物のNoSQLシステムに切り替えた方がまだましです。ref @t_wada: 列が実行時まで決まらず、有限のバリエーションに収まらないとき（例: エンドユーザーが作成するアンケートフォーム等）で、かつそれを EAV アンチパターンで解決したくないときに使います（バリエーションがそこまで多くないなら STI や CTI などのパターンで仕留めます） そらそうmrsekut.icon
そのJSON型を使うcolumnの中身は、常に同じ構造とは限らない
それはそう。
常に同じ構造に出来るなら正規化できるはずmrsekut.icon
構造が不定なものを無理やり一緒くたにしたいからJSON型を使うことになるはず
ということは、それを取得したアプリケーション側でかなりvalidaitonしないといけない
parseして構造を見ながら特定の型に変換していかないといけない
もっと悪いケースだと、そもそもアプリケーションで予測できない構造というのもありうる？
まじで自由に何でも入力できるフォームとかを作るとありそう
IDLで書いてJSONを生成する
deserializer,serializerも生成される
破壊的変更に対して強い
まず、 Protobuf のシリアライザとデシリアライザは、未知のフィールドを無視し、欠けているフィールドには型に合わせてゼロ値を補います。したがって、新しいコードで古いデータを読む場合や、逆に古いコードで新しいデータを読む場合（例えば、フロントエンドがバックエンドより後にデプロイされた場合）でも、クラッシュすることなく動作します。
また、使わなくなったフィールドを予約しておくことで、同じ名前のデータが再利用されるのを防ぐことも可能です。